Hi @hexart , there is another issue, which is in #chat-input, I type something then remove all, then the send button is not disabled properly. And users now can send empty messages. I wonder if that can also be fixed in this PR? Or should it be fixed in another PR.

there is another issue, which is in #chat-input, I type something then remove all, then the send button is not disabled properly. And users now can send empty messages. I wonder if that can also be fixed in this PR? Or should it be fixed in another PR.

I suggest handling the empty message validation in a separate PR. This current one focuses on DOM/rendering fixes, while input validation is a different concern. I'll create a new PR to address the send button and empty message issues.

No worry, I submitted a PR to fix the issue.

I am not sure what this section does

 const containsBlockElement = useMemo(
            () =>
              React.Children.toArray(props.children).some((child) => {
                if (!React.isValidElement(child)) return false;
                if (
                  /^h[1-6]$/.test(child.type as string) ||
                  child.type === 'p'
                ) {
                  return true;
                }
                if (
                  child.props?.['data-type'] === 'Alert' ||
                  (typeof child.type === 'function' &&
                    child.type.name === 'AlertComponent')
                ) {
                  return true;
                }
                if (React.isValidElement(child) && child.props?.children) {
                  return React.Children.toArray(child.props.children).some(
                    (grandChild) =>
                      React.isValidElement(grandChild) &&
                      (grandChild.type === 'div' ||
                        (typeof grandChild.type === 'string' &&
                          grandChild.type.toLowerCase() === 'div'))
                  );
                }
                return false;
              }),
            [props.children]

Other changes look good to me but it would be nice to have some comments explaining why we need to know if the paragraph contains certain blocks.

@willydouhard As I understand, that is for checking when to use p and when to use div for outer most element. If the elements have h1-h6 or have p or containing Alert or some of the grand children containing div, then the outer element should be div, otherwise it can be p.

Can't we always use a div then instead of adding logic?

@willydouhard the intention seems to keep the original <p> tag implementation. I think we can just use <div> tag and avoid this complex check. I can submit another PR without this check.

Can't we always use a div then instead of adding logic?

While using div everywhere might seem simpler, using semantic HTML tags like <p> when appropriate is important for:

• Accessibility (screen readers)
• SEO
• Document structure clarity

I'll add comments to explain this rationale in the code.

I don't think SEO is related in the chatbot context.

Can you explain why would div affect screen reader and document structure clarity? I do think this logic affect the maintenance effort of the project. Not sure if the benefit worth adding this complex check.

I don't think SEO is related in the chatbot context.

Can you explain why would div affect screen reader and document structure clarity? I do think this logic affect the maintenance effort of the project. Not sure if the benefit worth adding this complex check.

You make great points about the context of our application. You're right that in a chatbot UI, we might be over-engineering by adding complex checks for semantic HTML.

Would you be open to this simpler approach? Something like:

p(props) {
  const commonClassNames = 'leading-7 [&:not(:first-child)]:mt-4 whitespace-pre-wrap break-words';
  return <div {...omit(props, ['node'])} className={commonClassNames} role="paragraph" />;
}

That totally makes sense. changing "role" to paragraph and avoid this complex logic LGTM.

Thanks for fixing this. We kind of need this change before we can release with chainlit v2.

I guess we can also use role="article" if needed as mentioned here https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/article_role

I guess we can also use role="article" if needed as mentioned here https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/article_role

Yes, you're right, already fix it.